Skip to content

FrostyBackpack/udemy-application-security-the-complete-guide

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

16 Commits

image/README

image/README

 
 

README.md

README.md

 
 

Repository files navigation

Content

  • SDLC (Software Development Life Cycle)
  • Security
  • Introdution to OWASP Top 10 [2021]

SDLC (Software Development Life Cycle)

SDLC

  • Requirement Analysis
    Build out requirements for what it is that you are going to develop

    • High level view of requirements and goals
    • Extracts requirements or requirements analysis
    • Clients have an idea of what they want - not how
    • Scope defined and agreed with
    • Prioritization of requirements
    • Slotting of resources

  • Design
    Make your decisions around Technology and how it is going to actually be designed, what it is going to look like

    • Describe features and operations

      • Screen layout
      • Business rules
      • Process diagrams
      • Pseudo code and documentation

    • Prototype work

    • Detailed design

      • Technology choices
      • System architecture

  • Implementation
    Coding phase in SDLC, then you start testing and there is going to be some evolution

    • Input (Requirements and Design)

      • Requirements
      • Business Process
      • Business Rules
      • Software Design
      • Specification

    • Output

      • Deliverable Code

  • Testing
    Testing phase in SDLC

    • Static Analysis (Code testing)
    • Dynamic Analysis (Running software testing)
    • Unit testing (Verify the functionality of specific code)
    • Integration testing (Verify the interfaces between components)
    • Interface testing (Testing data passed between units)
    • System testing (Testing a completely integrated system)

  • Evolution
    Do some learnings from what you have built and put that into the requirements again to make enhancements to the development product that you have created

    Patch, Build, Test, Prod:
    You want to make sure that if there is any issues found such as security or even just defects, you want to patch those issues then rebuild, retest and then push it to production

Security

Security is anything you do to protect an asset that is vulnerable to some attack, failure, or error [threats]

  • Asset
    An asset is anything you deem to have value
    An asset may be valuable because:

    • It holds its value (E.g. gold/diamonds)
    • It produces value (E.g. Technology space, a server in a data center - running applications produce value to organization)
    • It provides access to value (E.g. a PIN number to a bank account to get money - something that needs to be protected)

  • Vulnerability
    A vulnerability is any weakness in an asset that makes it susceptible to attack of failure

  • Attack
    An attack is any intentional action that can reduce the value of an asset
    E.g. An attacker might perform a DDoS attack on that web server to reduce value for organisation intentionally

  • Failures + Errors
    Failures and errors are unintentional actions that can reduce the value of an asset
    E.g. There might be an unplanned outage because of a power outage or maybe a new push for a patch that gets pushed at web server that does not work that creates an outage for that web server, making it unavailable for organisation so it reduce value unintentionally

Attacks, Failures and Errors are actions that we collectively refer to as threats

Security Goals ("Anything")

Security, an more specifically Cybersecurity, can be understood as a set of goals

These goals are specifically defined by how we measure an asset's value

How does value define our security goals?

  • The goal of security is to protect an asset's value from threats
  1. Determine what assets we want to protect
  2. Learn how the asset works and interacts with other things
  3. Determine how our asset's value is reduced directly and indirectly
  4. Take steps to mitigate the threats

We must consider the unique nature of it assets and capabilities when considering security goals.

CIA prinicples

When we protect something that provides access value, we are maintaining its confidentiality

  • Confidentiality
    Information is only available to those who should have access (we can do this through encryption and HTTPS when we talking about browser traffic)

When we protect something that holds its value, we are maintaining its integrity

  • Integrity
    Data is known to be correct and trusted (we can do this through hashing, checksum, sometimes digital signatures)

When we protect something that produces value, we are maintaining its availability

  • Availability
    Information is available for use by legitimate users when it is needed (we can do this through building high availability and redundancy into our system)

Real World Example

  • About a rocket

    • List assets
      (identifies what is actually on the rocket)
      Rocket itself, the food, the fuel, the water, the payload that is within the rocket, the equipment, the manifest, etc.
    • List vulnerabiltiies
      (possible vulnerabilties that impact rocket)
      A weak heat shield, faulty equipment, the hole could be too thin, etc.
    • List threats
      (attacks, failures, errors that impact rocket)
      Space debris, atmosphere, weather, pilot error, etc.

  • How we secure it
    Based on the list of vulnerabilties and threats, we can have different ways that we could mitigate it.
    For instance, we could make the hole thicker or with using more duarble material. However, that could also alter things in the sense that we might make the rocket heavier and therefore, we would need more fuel to get it up or we could have less cargo space.
    Hence, the concept is making sure that the mitigations and the security that we put around our assets are in line with what the actual assets value is and make sure that we're not compromising the asset further by creating more complicated mitigations or remediation strategies.

We have well defined goals and security mechanisms, but some mechanisms are better because they fit security principles

Security principles aid in selecting or designing the correct mechanisms to implement our goals

Protection of information in computer systems [Doc]
https://web.mit.edu/Saltzer/www/publications/protection/

Protection of Information in computer systems

Security Pyramid

OWASP WebGoat
https://owasp.org/www-project-webgoat/

Introduction to OWASP Top 10 [2021]

1. Broken Access Control
Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other user's accounts, view sensitive files, modify other users' data, change access rights, etc.

2. Cryptographic Failures
Failure to sufficiently protect data in transit or rest from exposure to unauthorized individuals. This can include poor usage of encryption or the lack of encryption all together.

3. Injection
Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

4. Insecure Design
Failing to build security into the application early in the design process through a process of threat modeling, and secure design patterns and principles.

5. Security Misconfiguration
Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigurated HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.

6. Vulnerable and Outdated Components
Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

7. Identification and Authentication Failure
Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, ot to exploit other implementation flaws to assume other users' identities temporarily or permanently.

8. Software and Data Integrity Failures
Code or infrastructure that does not properly protect against integrity failures like using plugins from untrusted sources that can lead to a compromise.

9. Insufficient Logging and Monitoring Failures
Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

10. Server-Side Request Forgery
SSRF occurs when an application fetches resources without validating the destination URL. This can be taken advantage of by an attacker who is able to enter a destination of their choosing.

OWASP Help

OWASP offers that are great hints and series and frameworks that can be leveraged during the development process and all throughout the testing, the application testing and development process.

OWASP Projects

  • Flagship The OWASP Flagship destination is given to projects that have demonstrated strategic value to OWASP and application security as a whole
  • Lab OWASP Labs projects represent projects that have produced a deliverable of value
  • Incubator OWASP Incubator projects represent the experimental playground where projects are still being fleshed out, ideas are still being proven and development is still underway
  • Low Activity These projects had no release in at least a year. However, have shown to be valuable tools Code [Low Activity] Health Check February 2016

How to start with OWASP

OWASP Top 10: the classic guideline
https://owasp.org/www-project-top-ten/

OWASP Cheat Sheets to get into stuff without getting annoyed
https://github.com/OWASP/CheatSheetSeries

Tools:

SANS 25

https://www.sans.org/top25-software-errors/

SANS 25

Examples in the Top 25 Example SANS Top 25

Example SANS Top 25 (2)

OWASP vs SANS

OWASP vs SANS

Threat Actors and Definition

  • Confidentiality
    Concept of preventing the disclosure of information to unauthorized parties
  • Integrity
    Refers to protecting data from unauthorized alteration
  • Availability
    Access to systems by authorized personnel can be expressed as the system's availability
  • Authentication
    Authentication is the process of determining the identity of a user
  • Authorization
    Authorization is the process of applying access control rules to a user process, determining whether or not a particular user process can access an object
  • Accounting (Audit)
    Accounting is a means of measuring activity
  • Non-Repudiation
    Non-Repudiation is the concept of preventing a subject from denying a previous action with an object in a system
  • Least Privilege
    Subject should have only the necessary rights and privileges to perform its current task with no additional rights and privileges
  • Separation of Duties
    Ensures that for any given task, more than one individual needs to be involved
  • Defense in Depth
    Defense in depth is also known by the terms layered security (or defense) and diversity defense
  • Fail Safe
    When a system experiences a failure, it should fail to a safe state (Doors open when there is a power failure)
  • Fail Secure
    The default state is locked or secured. So a fail secure lock locks the door when power is removed.
  • Single point of failure
    A single point of failure is any aspect of a system that, if it fails, the entire system

Types of attackers

  • Script Kiddies

    • Low skill
    • Looking for easy and simple attacks
    • Motivated by revenge or fame

  • Hacktivist

    • Moderate to high skill
    • Looking to make an example of an organisation
    • Motivated by activism

  • Hackers

    • High skill
    • Looking to understand how things work
    • Motivation varies

  • Cyber Criminals

    • High skill
    • Looking for financial exploits
    • Motivated money (Ransomware, Cryptojacking)

  • Advanced Persistent Threat

    • Very high skill, deep pockets
    • Looking to commit cyber attacks in order to weaken a political advesary
    • Driven largely by national interest

Defense effort against threat actors

Defense effort against threat actors

Identifying Vulnerabilities

  • CVE (Common Vulnerabilities and Exposure)
    https://cve.mitre.org/cve/

    • Common Vulnerabiltiies and Exposures is a list of common identifiers for publicly known cyber security vulnerabiltiies

      • One identifier for one vulnerability with one standardized description
      • A dictionary rather than a database
      • The way to interoperability and better security coverage
      • A basis for evaluation among services, tools and database
      • Industry-endorsed via the CVE Numbering Authorities, CVE Board, and numerous products and services that include CV

  • CVSS (Common Vulnerability Scoring System)
    https://nvd.nist.gov/vuln-metrics/cvss

    • Common Vulnerability Scoring Sytem provides a way to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity. The numerial score can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organisations properly assess and prioritize their vulnerability management processes

  • CWE (Common Weakness Enumeration)
    https://cwe.mitre.org/

    • Common Weakness Enumeration is a community-developed list of common software security weaknesses. It serves as a common language, a measuring stick for software security tools, and as a baseline for weakness identification, mitigation, and prevent efforts

    • As its core, the Common Weakness Enumeration is a list of software weaknesses types

    • Three types:

      • Research This view is intended to facilitate research into weaknesses, including their inter-dependencies and their role in vulnerabilities
      • Development This view organizes weaknesses around concepts that are frequently used or encountered in software development
      • Architecture This view organizes weaknesses according to common architectural security tactics

Defense of depth

Exploitation of a vulnerability by a threat results in risk.

Anatomy of an attack

  • Vulnerability: Adobe Flash CVE-2016-0960
  • Exploit: Code written to take advantage of the vulnerability
  • Payload: Ransomware, Trojan, RAT, keylogger, etc.

Defense in depth is an approach to cybersecurity in which a series of defensive mechanisms are layered in order to protect valuable data and information. If one mechanism fails, another setps up immediately to thwart an attack.

What does it look like in the Cyber World Cyber World

  • Do not rely on defense in depth to always protect your app
  • Systems fail they can be circumvented by the weakest link
  • Your app may not always be behind those defenses

Proxy Tools

In normal web interaction between a client and an application, there is a HTTP request and response.

Your application is expecting requests to come in from a client. And the client could be a browser/mobile app/API which is going to make a request to your application and it is going to hit the web server.

Depending on what your application is and how its architecture is built, it is going to take that request and process it and return a response.

So this request and response interaction between the client and application is an HTTPS communication.

Normal Web Interaction

Hence, what a proxy does, where proxy tool does, is that it sits between your browser and the web server and will actually proxy or capture that traffic and before ift is sent to the web server. This gives you the ability to see what the request is and what that request looks like before it goes to web server and what that response from the web server is coming back (able to capture both the request and response - acts as an intermediary between browser and web server)

Proxy

Different tools:

API Security

Application Programming Interfaces (APIs) allow the creation of discrete functionality that is available through a function or HTTP call to the functionality.

This allows for a modular approach to building an overall application.

For instance, JavaScript has APIs available that are built on top of the base language that allow the developer to integrate additional functionality:

  • Browser APIs Built into the browser, these expose data from the browser and environment that the browser is running in
  • 3rd Party APIs These are APIs that are pulled in from external sources that allow you to retrieve data and functionality from that 3rd party

Difference between APIs and Standard application APIs vs Standard App

OWASP API Security Top 10

Broken object level authorization Mass assignment
Broken authentication Security misconfiguration
Excessive data exposure Injection
Lack of resource and rate limiting Improper assets management
Broken function level authorization Insufficient logging and monitoring
Broken Object Level Authorization

  • Definition Attacker substitutes ID of their resource in API call with an ID of a resource belonging to another user. Lack of proper authorization checks allows access. This attack is also known as IDOR (Insecure Direct Object Reference)

  • Example An API that allows for an attacker to replace parameters in the URL that allows the attackers to have access to an API that they should not have access to. The API is not checking permissions and lets the call through.

  • Prevention

    • Implement access checks on every call
    • Do not rely on user supplied IDs, only use IDs in the session object
    • Use random, non-guessable IDs
Broken Authentication

  • Definition Poorly implemented API authentication allowing attackers to assume other users' identities.

  • Example Unprotected APIs, weak authentication, not rotating or reusing API keys, poor password usage, lack of token validation and weak handling

  • Prevention

    • Check all authentication methods and use standard authentication, token generation/management, password storage, and MFA
    • Implement a strong password reset API
    • Authenticate the client calls to API
    • Use rate-limitations to avoid brute forcing
Excessive Data Exposure

  • Definition API exposing a lot more data than the client legitimately needs, relying on the client to do the filtering. Attacker goes directly to the API and has it all.

  • Example Returning full data objects from the database or allowing for direct access to sensitive data.

  • Prevention

    • Never rely on the client to filter data, and tailor API responses to the needs of the consumer. Ensure that there is a need-to-know for any PII returned
    • Ensure error responses do not expose sensitive information
Lack of Resource and Rate Limiting

  • Definition API is not protected against an excessive amount of calls or payload sizes. Attackers use that for DoS and brute force attacks.

  • Example Attacker performs a DDoS or otherwise overwhelms the API.

  • Prevention

    • Include rate limting, payload size limits, check compression ratios, and limit container resources
Broken Function Level Authorization

  • Definition API relies on client to use user level or admin level APIs. Attacker figures out the "hidden" admin API methods and invokes them directly.

  • Example Administrative functions that are exposed to non-admin users.

  • Prevention

    • Deny all access by default and build permissions from there based on specific roles
    • Test authorization through tools and manual testing
Mass Assignment

  • Definition The API takes data that client provides and stores it without proper filtering for allow-listed properties.

  • Example Payload received from the client is blindly transformed into an object and stored.

  • Prevention

    • Do not automatically bind incoming data without validating it first through an explicit list of parameters and payloads that you are expecting
    • Use a readOnly schema for properties that should never be modified
    • Enforce the defined schemas, types, and patterns that are accepted
Security Misconfiguration

  • Definition Poor configuration of the APIs servers allows attackers to exploit them.

  • Example Numerous issues like unpatched systems, overexposed files and directories, missing or outdated configuration, exposed systems and unused features, verbose error messaging.

  • Prevention

    • Use of hardened images and secure default configuration
    • Automation to detect (and repair) discovered misconfiguration
    • Disable unnecessary features, and limit admin access
Injection

  • Definition Attacker constructs API calls that include SQL-, NoSQL-, LDAP-, OS- and other commands that the API or backend behind it blindly executes.

  • Example SQL, LDAP, OS, XML injection

  • Prevention

    • Never trust end-user input
    • Have well-defined input data: schemas, types, string patters, etc.
    • Validate, filter, sanitize and quarantine (if needed) data from users
Improper Assets Management

  • Definition Attacker finds non-production versions of the API: such as staging, testing, beta or earlier versions - that are not as well protected and uses those to launch the attack.

  • Example Backwards compatibility can leave legacy systems exposed. Old and non-production versions can be poorly maintained yet still have access to production data. These also allow for lateral movement in the system.

  • Prevention

    • Properly inventory your systems and APIs
    • Limit access to anything that should not be public and properly segregate prod and non-prod environments
    • Implement security controls on the network and system such as API firewalls
    • Have a decommission process for old APIs and systems
Insufficent Logging and Monitoring

  • Definition Lack of proper logging, monitoring, and alerting let attacks go unnoticed.

  • Example Logging and alerts go unnoticed or are not responded to. Logs are not protected against tampering and are not integrated into a centralized logging system like a SIEM.

  • Prevention

    • Properly log sensitive workflows like failed login attempts, input validation failures, and failures in security policy checks
    • Ensure logs are formatted so that they can be imported in a centralized tool. Logs also need to be protected from tampering and exposure to unauthorized users
    • Integrate logs with monitoring and alerting tools

Dive into OWASP Top 10

Broken Access Control [# 1]

https://owasp.org/Top10/A01_2021-Broken_Access_Control/

  • Authorization is the process where requests to access a resource should be granted or denied. It should be noted that authorization is not equivalent to authentication - as these terms and their definitions are frequently confused

  • Authentication is providing and validating identity

  • Authorization includes the execution rules that determines what functionality and data the user (or Principal) may access, ensuring the proper allocation of access rights after authentication is successful

  • Having a license does not mean you are granted access to a military base. You have authentication, but not authorization

  • Access Control Access Control

  • Common Vulnerabiltiies

    • Violation of the principle of least privilege or deny by default, where access should only be granted for particular capabilities, roles, or users, but is available to anyone
    • Bypassing access control checks by modifying URL internal application state, or the HTML page, or simply using a custom API attack tool
    • Permitting viewing or editing someone else's account, by providing its unique idenitifier (insecure direct object references)
    • Accessing APIs that do not have proper access controls around HTTP verbs (PUT, POST, DELETE)
    • Elvation of privilege. Acting as a user without being logged in, or acting as an admin when logged in as a user
    • Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token or a cookie or hidden field manipulated to elevate privileges, or abusing JWT invalidation
    • CORS misconfiguration allows unauthorized API access
    • Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user. Accessing API with missing access controls for POST, PUT, and DELETE

  • Prevention

    • Apart from public resources, deny by default
    • Implement access control mechanisms once and re-use them throughout the application, including minimizing CORS usage
    • Model access controls should enforce record ownership, rather than accepting that the user can create, read, update or delete any record
    • Disable web server directory listing and ensure file metadata (e.g. git) and backup files are not present within web roots
    • Log access control failures, alert admins when appropriate (e.g. repeated failures)
    • Rate limit API and controller access to minimize the harm from automated attack tooling
    • JWT tokens should be invalidated on the server after logout

  • Example 1

    • The application uses unverified data in a SQL call that is accessing account information:
      
    pstmt.setString(I, request.getParameter("acct"));
    ResultSet results = pstmt.executeQuery();

  • Example 2

    • An attacker simply forces browser to target URLs. Admin rights are required for access to the admin page
      
    http://example.com/app/getappInfo
    http://example.com/app/admin_getappInfo
    • If an unauthenticated user can access either page, its a flaw. If a non-admin can access the admin page, this is a flaw

Cryptographic Failures [# 2]

https://owasp.org/Top10/A02_2021-Cryptographic_Failures/

  • Data Protection

    • Protected Health Information (PHI)
      Names, Dates, Phone/Fax Numbers, Email, SSN, MRN, Account Numbers, Biometric (finger, retinal, voice prints), Images
    • Personally Identifiable Information (PII)
      Name, Address, Passport, Vehicle information, Drivers license, Credit card numbers, Digital identity, birthplace, genetic information, login name
    • Sensitive Financial Information
      Credit/Debit card numbers and security codes, Account numbers, loan agreements, loan details, Tax ID, PoS transactions

  • Cryptographic FailuresCryptographic Failures

  • Defense Cryptographic Failures (Defense)

  • Example

    • A site does not use or enforce TLS for all pages or supports weak encryption. An attacker monitors network traffic (e.g. at an insecure wireless network), downgrades connections from HTTPS to HTTP, intercepts requests and steals the user's session cookie. The attcker then replays this cookie and hijacks the user's (authenticated) session, accessing or modifying the user's private data. Instead of the above, they could alter all transported data (e.g. the recipient of a money transfer)

Injection [# 3]

https://owasp.org/Top10/A03_2021-Injection/

  • Injection Anytime user input changes the intended behaviour of the system

  • How does it happen

    • Trust of user input without validating, filtering, or sanitizing
    • Dynamic queries are used directly in an interpreter without escaping
    • Extracting additional information from by taking advantage weaknesses in search parameters used in object-relational mapping
    • Using input directly in a SQL command that is used for queries or commands

  • SQL Injection

    • Allows attackers to manipulate SQL statements sent to a database from the web applicaiton
    • Exploits inadequate validation and sanitization of user-supplied input

  • SQL Injection Potential Impact

    • Steal all data from the database
    • Access PII/PHI/PCI Data
    • Take over backend server or entire network
    • Remove data

  • Example (SQLI) An application uses untrusted data in the construction of the following vulnerable SQL call:

      
    String query = "SELECT \* FROM accounts WHERE custID = " + request.getParameter("id") + "";

    Similarly, an application's blind trust in frameworks may result in queries that are still vulnerable (e.g. Hibernate Query Language (HQL))

      
    Query HQLQuery = session.createQuery("FROM accounts WHERE custID=" + request.getParamter("id") + "");

    In both cases, the attacker modifies the "id" parameter value in their browser to send: ' or 'I'='I

    For instance: http://example.com/app/accountView?id=' or 'I'='I

    This changes the meaning of both queries to return all the records from the accounts table. More dangerous attacks could modify or delete data or even invoke stored procedures

  • Other Injection Flaws

    • OS Command OS Injection
      OS Injection (2)
    • LDAP LDAP
    • XPATH XPATH

  • Example

    • http://example/defaul.aspx?user=\*
    • In the example above, we send the _ character in the user parameter which will result in the filter variable in the code to be initialized with (samAccountName=_)
    • The resulting LDAP statement will make the server return any object that contains the samAccountName attribute. In addition, the attacker can specify other attributes to search for and the page will return an object matching the query

  • Prevention

    • Utilize a parametrized interface to the database
    • Positive server-side input validation (e.g. allow-list of valid input)
    • Escape special characters in the query flow
    • Limit the return of records in a query using SQL controls like LIMIT (record count)

Insecure Design [# 4]

https://owasp.org/Top10/A04_2021-Insecure_Design/

  • Insecure Design

    • Insecure design happens when we do not use secure design patterns
    • Often thought of as security requirements/reference architecture when we do not have a paved road methodology (essentially placing secure guardrails around the development and deployment of application) that also leads us to insecure design
    • When we are not doing threat modeling (allows us identify threats and risks early on in the process and build in those requirements into the design early on), that also leads to insecure design

  • How to Prevent

    • Establish and use a secure development lifecycle with AppSec professionals to help evaluate and design security and privacy-related controls
    • Establish and use a library of secure design patterns or paved road ready to use components
    • Use threat modeling for critical authentication, access control, business logic, and key flows
    • Integrate security language and controls into user stories
    • Integrate plausibility checks at each tier of your application (from frontend to backend)
    • Write unit and integration tests to validate that all critical flows are resistant to the threat model. Compile use-cases and misuse-cases for each tier of your application
    • Segregate tier layers on the system and network layers depending on the exposure and protection needs
    • Segregate tenants robustly by design throughout all tiers
    • Limit resource consumption by user or service

  • Defences

    • Use a secure development lifecycle with security professionals for guidance
    • Create secure design patterns and architectures that can be reused to create a paved road
    • Threat model critical application workflows
    • Write secure unit and integration tests that use abuse and misuse cases
    • Design for segregation of tenants

  • Bad Bots

    • A retail chain's e-commerce website does not have protection against bots run by scalpers buying high-end video cards to resell auction websites. This creates terrible publicity for the video card makers and retail chain owners and enduring bad blood with enthusiasts who cannot obtain these cards at any price. Careful anti-bot design and domain logic rules, such as purchases made within a few seconds of availability, might identify inauthentic purchases and rejected such transactions

Security Misconfiguration [# 5]

https://owasp.org/Top10/A05_2021-Security_Misconfiguration/

  • Absence of security settings in

    • Application
    • Framework
    • Database
    • Web server
    • Platform

  • Lack of

    • Patching
    • Secure settings for parsers
    • Outdated security configuration
    • Default settings/passwords
    • Overly verbose messaging when an error occurs
    • Out of date software

  • Defences

    • Hardened secure defaults that are used to deploy in other environments in an automated method. Each environment should be configured identically with the same security controls
    • Reduce the extra features and frameworks that are not needed for used
    • Use a change management board to verify changes to environments and provide a gate for significant changes
    • Segment components and use automated tools to verify configuration and detect drift

  • Default settings in the cloud

    • A cloud service provider (CSP) has default sharing permissions open to the Internet by other CSP users. This allows sensitive data stored within cloud storage to be accessed

Using Known Vulnerable Components [# 6]

https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/

  • Dependency

    • Dependency is a broad software engineering term used to refer when a piece of software relies on another one

    Dependency

  • Vulnerable and Outdated Components

    • The term "Components" in the title of this category refers to application frameworks, libraries or other software modules integrated into an application: such components are usually written by a 3rd Party but this is not exclusive
    • This category references using these components when they may have malicious code or security weaknesses within them (e.g. vulnerable)

  • Defences - Commercial

    • Most applications include either commercial products or Open Source Software (OSS) within their software bundles
    • For commercial products, most major vendors such as Oracle, Google and IBM provide Security Bulletins to distribution lists for notification purposes. Make sure you are signed up for these services

  • Defences - Open Source Software

    • For Open Source Software (OSS) libraries find a solution like Dependency Check, GitLab, or Jfrong, Xray, to automatically scan for vulnerable packages
    • Sign-up for regular security bulletins from the National Vulnerability Database (https://nvd.nist.gov/Home/Email-List) and regularly monitor components for security issues and updated versions

  • General Defence

    • Do not give extreme trust in any 3rd party component
    • Always verify its size and checksum and download directly from vendor website, never a secondary party
    • Challenge the vendor to provide evidence of security vulnerability scanning. If possible, scan it yourself
    • Use well-known vendors and sources that are maintained
    • Remove unnecessary components from your code if they are not in use

  • Example

    • Components typically run with the same privileges as the application itself, so flaws in any component can result in serious impact. Such flaws can be accidental (e.g. coding error) or intentional (e.g. a backdoor in a component)
    • Some example exploitable component vulnerabilities discovered are:
      • CVE-2017-5638, a Struts 2 remote code execution vulnerability that enables the execution of arbitary code on the server, has been blamed for significant breaches
      • While the Internet of Things (IoT) is frequently difficult or impossible to patch, the importance of patching them can be great (e.g. biomedical devices)
    • There are automated tools to help attackers find unpatched or misconfigured systems. For example, the Shodan IoT search engine can help you find devices that still suffer from HeartBleed vulnerability patched in April 2014

  • Notification

    • Have a means for receiving notifications on potentially vulnerable software
    • Many vendors like Microsoft already offer a notification service, however other services or feeds exist
    • Receiving notification is only part of the solution. You must also be able to:
      • Know where to patch (what systems or software are vulnerable)
      • Have the ability to test the new patch
      • Have a means to deliver the patch
      • Ability to notify those impacted by the changes to the system (users, customers, etc)

  • Patching Process Patching Process

Identification and Authentication Failures [# 7]

https://owasp.org/Top10/A07_2021-Vulnerable_and_Outdated_Components/

  • How can Authentication be broken Broken Authentication

  • Attacks

    • Password guessing attack (social engineering)
      • John from IT, needs your help ...
    • Dictionary attack
      • Dictionary words that are hashed and tested
    • Brute force attack
      • Guessing or targeted hashes
    • Username enumeration
      • Guessable patterns of usernames or log in failure messages that reveal too much
    • Phishing
      • Trick users into providing their credentials to an imposter, look-alike site

  • Account Recovery Risks

    • Social Engineeing
      • Emailing a password reset form without using something like two factor
    • Easily guessable security answers
      • "What school did you attend"
    • Password sent through insecure channels
      • Email
    • Password change not required
      • Once you have been given a new password, it should be changed on the next login

Software and Data Integrity Failures [# 8]

https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/

  • Software Integrity Failures Software Integrity Failures

  • Software Integrity Prevention Software Integrity Prevention

  • Example

    • SolarWinds malicious update: Nation-states have been known to attack update mechanisms, with a recent notable attack being the SolarWinds Orion attack. The company that develops the software had secure build and update integrity processes. Still, these were able to be subverted, and for several months, the firm distributed a highly targeted malicious update to more than 18,000 organisations, of which around 100 or so were affected. This is one of the most far-reaching and most significant breaches of this nature in history

Security Logging and Monitoring Failures [# 9]

https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/

  • Security Logging and Monitoring Failures

    • Exploitation of insufficient logging and monitoring is the bedrock of nearly every major incident. Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected
    • Most successful attacks start with vulnerability probing. Allowing such probes to continue can raise the likelihood of successful exploit to nearly 100%
    • Between October 1, 2020, through December 31, 2021, the median number of days between compromise and detection was 21, down from 24 days in 2020 (itbrew.com)
      • In 2016, identifying a breach took an average of 191 days
    • Insufficient logging, detection, monitoring and active response occurs any time:
      • Auditable events, such as logins, failed logins, and high-value transactions are not logged
      • Warnings and errors generate no, inadequate or unclear log messages
      • Logs of applications and APIs are not monitored for suspicious activity or logs are only stored locally
      • Appropriate alerting thresholds and response escalation processes are not in place or effective
      • Penetration testing and scans by DAST tools (such as OWASP ZAP) do not trigger alerts
      • The application is unable to detect, escalate, or alert for active attacks in real time or near real time
      • Plans for monitoring, and response should be developed and well known to the organisation

  • Good Practices

    • As per the risk of the data stored or processed by the application:
      • Ensure all login, access control failures, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts, and held for sufficient time to allow delayed forensic analysis
      • Ensure that logs are generated in a format that can be easily consumed by a centralized log management solutions
      • Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar
      • Establish effective monitoring and alerting such that suspicious activities are detected and responded to in a timely fashion
      • Establish or adopt an incident response and recovery plan

  • SIEM (Security Information and Event Management) SIEM

Server-Side Request Forgery (SSRF) [# 10]

https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery/

  • SSRF occurs when we do not SSRF

  • Defenses

    • From Network Layer

      • Segment remote resource access functionality in separate networks to reduce the impact of SSRF
      • Enforce "deny by default" firewall policies or network access control rules to block all but essential intranet traffic

    • From Application Layer

      • Sanitize and validate all client-supplied input data
      • Enforce the URL schema, port, and destination with a positive allow list
      • Do not send raw responses to clients
      • Disable HTTP redirections
      • Be aware of the URL consistency to avoid attacks such as DNS rebinding and "time of check, time of use" (TOCTOU) race conditions

  • Example

    • Sensitive data exposure

      • Attackers can access local files or internal services to gain sensitive information such as file:///etc/passwd and http://localhost:28017/

    • Compromise internal services

      • The attacker can abuse internal services to conduct further attacks such as Remote Code Execution (RCE) or Denial of Service (Do)

Defense and Tools

Cross Site Scripting

  • Cross Site Scripting (XSS)

    • Is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy
    • This subversion is possible because the web application fails to properly validate input from the web browser (e.g. client) and/or fails to properly escape that input in the response

    Cross-Site Scripting

    Cross-Site Scripting (2)

Content Security Policy (CSP)

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

  • Content Security Policy (CSP)

    • Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks
    • To enable CSP, you need to configure your web server to return the Content-Security-Policy HTTP header
    • Browsers that do not support it will work with servers that implement it and vice versa; browsers that do not support CSP simply ignore it, functioning as usual, defaulting to the standard same-origin policy for web content

  • Mitigating XXS

    • CSP makes it possible server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that the browser should consider to be valid sources of executable scripts
    • A CSP compatible browser will then only execute scripts loaded in source files received from those whitelisted domains, ignoring all other script (including inline scripts and event-handling HTML attributes)
    • As an ultimate form of protection, sites that want to never allow scripts to be executed can opt to globally disallow script execution

  • Writing a Policy

    • A policy is described using a series of policy directives, each of which describes the policy for a certain resource type of policy area
    • A policy needs to include a default-sec or script-src directive to prevent inline scripts from running, as well as blocking the use of eval()
    • Your policy should include a default-src policy directive, which is a fallback for other resource types when they do not have policies of their own
    • A policy needs to include a default-src or style-src directive to restrict inline styles from being applied from a <style> element or a style attribute

  • Directives CSP 1.0

    • connect-src (d)
      restricts which URLs the protected resource can load using script interfaces (e.g. send() method of an XMLHttpRequest object)
    • font-src (d)
      restricts from where the protected resource can load fonts
    • img-src (d)
      restricts from where the protected resource can load images
    • media-src (d)
      restricts from where the protected resource can load video, audio, and associated text tracks
    • object-src (d)
      restricts from where the protected resource can load plugins
    • script-src (d)
      restricts which scripts the protected resource can execute. Additional restrictions against inline scripts and eval. Additional directives in CSP2 for hash and nonce support
    • style-src (d)
      restricts which styles the user may applies to the protected resource. Additional restrictions against inline and eval
    • default-src (d)
      covers any directive with
    • frame-src
      restricts from where the protected resource can embed frames. Note, deprecated in CSP2
    • report-url
      specifies a URL to which the user agent sends reports about policy violation
    • sandbox
      specifies an HTML sandbox policy that the user agent applies to the protected resource. Optional in 1.0

  • Directives CSP 2.0

    • form-action
      restricts which URLs can be used as the action of HTML form elements
    • frame-ancestors
      indicates whether the user agent should allow embedding the resource using a frame, iframe, object, embed or applet element or equivalent functionality in non-HTML resources
    • plugin-types
      restricts the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded
    • base-uri
      restricts the URLs that can be used to specify the document URL
    • child-src (d)
      governs the creation of nested browsing contexts as well as Worker execution contexts

  • Sample CSP Sample

Security Models

  • Security Models

    • Security models are used to understand the systems and processes developed to enforce security principles
    • Three key elements play a role in systems with respect to model implementation: People, Processes, Technology
    • Addressing a single element of the three may provide benefits, but more effectiveness can be achieved through addressing multiple elements
    • How security models are used in an OS design:
      Security Model

  • Access Control Models

    • Access Control List (ACL)
      A list of permissions attached to an object. An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects
    • Bell-LaPadula model
      The model is a formal state transition model of computer security policy that describes a set of access control rules which use security labels on objects and clearances for subjects. Security labels range from the most sensitive (e.g. "Top Secret"), down to the least sensitive (e.g. "Unclassified" or "Public")
    • Role-based Access Control
      Role-based access control (RBAC) is a policy-neutral access-control mechanism defined around roles and privileges. The components of RBAC such as role-permissions, user-role and role-role relationships make it simple to perform user assignments
    • Access-based Access Control
      Also known as policy-based access control, defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes, etc.) This model supports Boolean logic, in which rules contain "IF, THEN" statements about who is making the request, the resource and the action

  • Multi-level Security Model - Integrity Model

    • Biba Integrity Model
      The model is designed so that subjects may not corrupt data in a level ranked higher than the subject, or be corrupted by data from a lower level than the subject. In the Biba model, users can only create content at or below their own integrity level (a monk may write a prayer book that can be read by commoners, but not one to be read by a high priest) Conversely, users can only view content at or above their own integrity level (a monk may read a book written by the high priest, but may not read a pamphlet written by a lowly commoner)
    • Clark-Wilson Model
      Instead of defining a formal state machine, the model defines each data item and allows modifications thorugh only a small set of programs. The model uses a three-part relationship of subject/program/object (where program is interchangeable with transaction) known as a triple or an access control triple. Within this relationship, subjects do not have direct access to objects. Objects can only be accessed through programs

  • Multi-level Security Model - Information Flow Model

    • Brewer-Nash Model (Chinese Wall)
      Technology can be employed to prevent access to data by conflicting groups. People can be trained not to compromise the separation of information. Policies can be put in place to ensure that the technology and the actions of personnel are properly engaged to prevent compromise
    • Data Flow Diagrams
      Specifically designed to document the storage, movement and processing of data in a system. They are constructed on a series of levels. The highest level, level 0, is a high-level contextual view of the data flow through the system. The next level, level 1, is created by expanding elements of the level 0 diagram. This level can be exploded further to a level 2 diagram, or the lowest-level diagram of a system
    • Use Case Models
      Requirements from the behavioral perspective provide a description of how the system utilizes data. Use cases are constructed to demonstrate how the system processes data for each of its defined functions
    • Assurance Models
      The level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its lifecycle, and that software functions in the intended manner

Software Composition Analysis (SCA)

  • Software Composition Analysis (SCA)

    • SCA is the process of validating that the components, libraries and opensource software that is used in an application is free from known vulnerabilities and license compliance

    • These external software components can come from several places:

      • Downloads
      • Commercial applications
      • Third-party libraries and software
      • From outsource development by consulting

    • SCA can provide:

      • Component tracking and inventory
      • Vulnerability identification and remediation recommendation
      • License management

    SCA

  • OWASP Dependency Check

    • .NET and Java compatible, Dependency Check is used to scan libraries used as build dependencies during the build process
    • Dependencies are matched against the NVD (National Vulnerability Database) to determine whether the dependency being used is vulnerable
    • A report is generated and can be used to identify the dependencies as well as understand the mitigation (In mos t cases, the mitigation is to use the most up to date level of software)

  • National Vulnerability Database
    https://nvd.nist.gov/

    • The NVD is the U.S government repository of standards based vulnerability mmanagement data represented using Security Content Automation Protocol (SCAP) This data enables automation of vulnerability management, security measurement, and compliance
    • The NVD includes databases of security checklist references, security related software flaws, misconfigurations, product names and impact metrics

    NVD

    • Sample Dependency Check
    • JFrog Xray JFrog JFrog Xray

Security Knowledge Framework

  • Security Knowledge Framework (SKF)

    • The OWASP Security Knowledge Framework is intended to be a tool that is used as a guide for building and verifying secure software
    • Education is the first step in the Secure Software Development Life Cycle
    • "The OWASP Security Knowledge Framework is an expert system web-application that uses the OWASP Application Security Verification Standard and other resources. It can be used to support developers in pre-development (security by design) as well as after code is released (OWASP ASVS
    • Level 1-3)"

  • Why

    • Security by design
    • Information is hard to find
    • Examples lack security details
    • Security is hard
    • Together we can create secure web applications
    • Defensive coaching approach
    • SKF is the first step in SDLC

  • How SKF can be used

    • Security Requirements OWASP ASVS for development and for third party vendor applications
    • Security knowledge reference (Code examples/Knowledge Base items)
    • Security is part of design with the pre-development functionality in SKF
    • Security post-development functionality in SKF for verification with the OWASP ASVS

  • Stages of Development

    • Pre development stage
      Here we detect threats beforehand and we provide developers with secure development patterns as well as providing feedback and solutions on how to handle their threats
    • Post development stage
      By means of checklists, we guide developers through a process where we harden their application infrastructure and functions by providing feedback and solutions

  • References

Secure Code Review

  • Who to include

    • Like threat modeling, you want to have the appropriate members involved in the review:
      • Developers
      • Architects
      • Security SME (Subject Matter Expert)
      • Depending on the portion of the application you may need to include the SME for that topic (Authentication, DB logic, User Experience ...)

  • Scope and Aid

  1. Code reviews should take into consideration the threat model and high-risk transactions in the application
  2. A completed threat model will highlight the areas of concern
  3. Any time code is added/updated in those high-risk areas a code review should include a security component
  4. When changes are required to the threat model due to findings during that code review, the threat model should be updated

  • Understand the risk
    Understand the risk

    • When considering the risk of code under review, consider some common criteria for establishing risk of a particular code module. The higher the risk, the more thorough the review should be

      • Application features and business logic
      • Context/Sensitive Data
      • The code (language, feature, nuance of language)
      • User roles and access rights (anonymous access?)
      • Application type (mobile, desktop, Web)
      • Design and architecture of the application
      • Company standards, guidelines and requirements that apply

    • The reviewer will need certain information about the development in order to be effective

      • Design documents, business requirements, functional specifications, test results and the like

    • If the reviewer is not part of the development team, they need to talk with developers and the lead architect for the application and get a sense of the application

      • Does not have to be a long meeting, it could be a whiteboard session for the development team to share some basic information about the key security considerations and controls

  • Information Gathering Tips

    • Walkthrough of the actual running application
    • A brief overview of the structure of the code base and any libraries
    • Knowing the architecture of the application goes a long way in understanding the security threats that are applicable
      • Tech Stack, deployment, users and data
    • All the required information of the proposed design including flow charts, sequence diagrams, class diagrams and requirements documents to understand the objective of the proposed design should be used as reference during the review

  • Performing the review (using the checklist)

    • When using the Code Review Checklist Template, the reviewer may filter out non-applicable categories
    • It is recommended that the complete list is used for code that is high risk. For instance, code that impacts patient safety workflows or mission critical functionality shall use the complete code review list
    • The code review template should be completed and appended during code check-in in the code repository or with the completed code review using a tool (Crucible)

  • When to perform the review

    • Code
      Pre-commit: Code review during pre-commit means that dangerous or sub-par code does not make it to the code branch. However, this does reduce the time to delivery of new code
    • Post
      Post-commit: This allows for faster delivery of software but runs the risk of allowing dangerous code into the branch. Other developers may also add their code which can make future reviews more cumbersome
    • Audit
      During a code audit: This can be triggered by an event such as a found vulnerability and should review the entire area of concern rather than focus on a single code commit

  • What to do with results
    A vulnerability or risk found during a code review should be addressed immediately if found in the pre-commit phase. However, there may be cases when code cannot be mitigated, or issues are found after code has been committed. In those cases, go through a Risk Rating to determine its impact and undestand the timeframe for remediation.

  • OWASP Secure Code Review

Session Management

Introduction to Session Management

  • Sessions

    • A web session is a sequence of network HTTP request and response transactions associated to the same user
    • Modern and complex web applications require the retaining of information or status about each user for the duration of multiple requests
    • Sessions provide the ability to establish variables (such as access rights and localization settings) which will apply to each and every interaction a user has with the web application for the duration of the session

    Web applications can create sessions to keep track of anonymous users after the very first user request

    • An example would be maintaining the user language preference

    Additionally, web applications will make use of sessions once the user has authenticated

    • This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application

    Therefore, current web applications can provide session capabilities both pre and post authentication

    Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application

    • such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina)

    HTTP is a stateless protocol where each request and response pair is independent of other web interactions.

    Session management links both the authentication and authorization modules commonly available in web applications:

    • The session ID or token binds the user authentication credentials to the user HTTP traffic and the appropriate access controls enforced by the web application
    • The complexity of these components in modern web applications, plus the fact that its implementation and binding resides on the web developer's hands makes the implementation of a secure session management module very challenging

    Session Management

  • Since HTTP and Web Server both are stateless, the only way to maintain a session is when some unique information about the session (session id) is passed between server and client in every request and response

  • Methods of Session Management:

    • User Authentication
      Common for a user to provide authentication credentials from the login page and then the authentication information is passed between server and client to maintain the session
    • HTML Hidden Field
      A unique hidden field in the HTML and when user starts navigating, we can set its value unique to the user and keep track of the session
    • URL Rewriting
      A session identifier parameter is appended to every request and response to keep track of the session
    • Cookies
      Cookies are small piece of information that are sent by the web server in the response header and gets stored in the browser cookies. When client make further request, it adds the cookie to the request header to keep track of the session

  • Federated Identity

  1. A federated identity in information technology is the means of linking a person's electronic identity and attributes, stored across multiple distinct identity management systems
  2. Federated identity is related to single sign-on (SSO), in which a user's single authentication ticket, or token, is trusted across multiple IT systems or even organisations
  3. The "federation" of identity describes the technologies, standards and use-cases which serve to enable the portability of identity information across otherwise autonomous security domains
    • Technologies:
      • Security Assertion Markup Language (SAML)
      • OAuth
      • OpenID
      • Security Tokens (Simple Web Tokens, JSON Web Tokens and SAML assertions)
      • Web Service Specifications and Windows Identity Foundation

Federated Identity

Web Server Session Management

  • Java Session Management (Cookies) Java Session Management

  • Java Session Management (HTTPSession)

    • Servlet API provides Session management through HttpSession interface. We can get session from HttpServletRequest object using following methods. HttpSession allows us to set objects as attributes that can be retrieved in future requests.

    • HttpSession getSession()
      This method always returns a HttpSession object. It returns the session object attached with the request, if the request has no session attached, then it creates a new session and return it

    • HttpSession getSession(boolean flag)
      This method returns HttpSession object if request has session else it returns null

    • When HttpServletRequest getSession() does not return an active session, then it creates the new HttpSession object and adds a Cookie to the response obejct with name JSESSIONID and value as session id

    • This cookie is used to identify the HttpSession object in further requests from client

  • Java Session Management (URL Rewrite)

    • There may be times where the browser has cookies disabled
    • The application may choose to pass session information in the URL
    • The URL can be encoded with HttpServletResponse encodeURL() method
      • In a redirect the request to another resource can be encoded with encodeRedirectURL() method
    • However: there is a clear security concern with the session in the URL

  • .NET Sessions Management
    .NET Session Management

    • .NET session state supports several different storage options for session data. Each option is identified by a value in the SessionStateMode enumeration. The following list describes the available session state modes:

    • You can specify which mode you want .NET session state to use by assigning a SessionStateMode enumeration values to the mode attribute of the sessionState element in your application's Web.config file. Modes other than InProc and Off require additional parameters, such as connection-string values

    • InProc mode, which stores session state in memory on the Web server. This is the default

    • StateServer mode is a somewhat slower service than the in-process variant since calls go to another server. All session data is stored in memory of the State Machine

    • SQLServer mode stores session state in a SQL Server database ensuring that session is maintained after an application is restarted and can be shared in a farm

    • Custom mode, which enables you to specify a custom storage provider

    • Off mode, which disables session state

  • In-Process

    • In-process mode is the default session state mode and is specified using the InProc SessionStateMode enumeration value
    • In-process mode stores session state values and variables in memory on the local Web server
    • It is the only mode that supports the Session_OnEnd event
    • The Session_OnEnd event occurs when a session is abandoned or times out

  • State Server Mode

    • StateServer mode stores session state in a process, referred to as the ASP.NET state service, that is separate from the ASP.NET worker process or IIS application pool. Using this mode ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm
    • To improve the security of your application when using StateServer mode, it is recommended that you protect your stateConnectionString value by encrypting the sessionState section of your configuration file

  • SQL Server Mode

    • SQLServer mode stores session state in a SQL Server database. Using this mode ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm
    • To use SQLServer mode, you must first be sure the ASP.NET session state database is installed on SQL Server

  • Custom Mode

    • Custom mode specifies that you want to store session state data using a custom session state store provider. When you configure your .NET application with a Mode of Custom, you must specify the type of the session state store provider using the providers sub-element of the sessionState configuration element. You specify the provider type using an add sub-element and include both a type attribute that specifies the provider's type name and a name attribute that specifies the provider instance name

JWT JSON Web Token

https://jwt.io/

  • JSON Web Token (JWT)

    • JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object
    • This information can be verified and trusted because it is digitally signed
      • JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA
    • Although JWTs can be encrypted to also provide secrecy between parties
      • Signed tokens can verify the integrity of the claims contained within it, while encrypted tokens hide those claims from other parties
      • When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it

  • Use Cases

    • Authorization
      This is the most common scenario for using JWT. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token

    • Information Exchange
      JSON Web Tokens are a good way of securely transmitting information between parties

      • Signed tokens - confirm senders are who they say they are
      • Hashed - verified that the content has not been tampered with

  • How it works
    In authentication, when the user successfully logs in using his credentials, a JSON Web Token will be returned and must be saved locally instead of the traditional approach of creating a session in the server and returning a cookie
    Whenever the user wants to access a protected route, it should send the JWT, typically in the Authorization header using the Bearer schema
    This is a stateless authentication mechanism as the user state is never saved in the server memory. The server's protected routes will check for a valid JWT in the Authorization header, and if there is, the user will be allowed
    As JWTs are self-contained, all the necessary information is there, reducing the need of going back and forward to the database
    JWT

  • Structure
    In its compact form, JSON Web Token consist of three parts separated by dots(.) which are:

    • Header
      The header typically consists of two parts: the type of token (JWT) and the hashing algorithm being used (such as HMAC, SHA256 or RSA)

      • Example
        JWT (Header)

    • Payload
      The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional data. There are three types of claims:

      • Registered claims
        These are a set of predefined claims which are not mandatory but recommended, to provide a set of useful, interoperable claims. Some of them are: iss(issuer), exp (expiration time), sub (subject), aud (audience) and others
      • Public claims
        These can be defined at will by those using JWTs. But to avoid collisions they should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant namespace
      • Private claims
        These can the custom claims created to share information between parties that agree on using them and are neither registered or public claims
      • Example
        JWT (Payload)

    • Signature
      To create the signature part, you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that

      • Example
        JWT (Signature)

Therefore, a JWT typically looks like the following.
(xxxxx.yyyyy.zzzzz)

OAuth

https://oauth.net/

  • OAuth

    • OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords
    • This mechanism is used by companies such as Amazon, Google, Facebook, Microsoft and Twitter to permit the users to share information about their accounts with third party applications or websites OAuth (Social Media)
    • OAuth decouples authentication from authorization and supports multiple use cases addressing different device capabilities. It supports server-to-server apps, browser-based apps, mobile/native apps, and consoles/TVs
    • OAuth is a delegated authorization framework for REST/APIs. It enables apps to obtain limited access (scopes) to a user's data without giving away a user's password
    • Designed specifically to work with HTTP, OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server

  • OAuth Actors OAuth Actors

  • OAuth Scopes OAuth Scopes

  • OAuth Tokens

    • Access tokens are the token the client uses to access the Resource Server (API). They are meant to be short-lived. Think of them in hours and minutes, not days and month. Because these tokens can be short lived and scale out, they cannot be revoked, you just have to wait for them to time out
    • The other token is the refresh token. This is much longer-lived; days, months, years. This can be used to get new tokens and can be revoked to kill an applications access
    • The OAuth spec does not define what a token is. It can be in whatever format you want. Usually though, you want these tokens to be JSON Web Tokens

    Tokens are retrieved from endpoints on the authorization server.

    • The authorize endpoint is where you go to get consent and authorization from the user
    • The token endpoint provides the refresh token and access token

    You can use the access token to get access to APIs. Once it expires, you will have to go back to the token endpoint with the refresh token to get a new access token. OAuth OAuth (2)

Open ID

  • OpenID 1.0 and 2.0

    • OpenID is an open standard and decentralized authentication protocol promoted by the non-profit OpenID Foundation
      • It allows users to be authenticated by co-operating sites (known as relying parties, or RP) using a third-party service, eliminating the need for webmasters to provide their own ad hoc login systems, and allowing users to log into multiple unrelated websites without having to have a separate identity and password for each
    • The OpenID standard provides a framework for the communication that must take place between the identity provider and the OpenID acceptor (the "relying party")
    • The OpenID protocol does not rely on a central authority to authenticate a user's identity
      • Neither services nor the OpenID standard may mandate a specific means by which to authenticate users, allowing for approaches ranging from the common (such as passwords) to the novel (such as smart cards or biometrics)

  • OpenID https://openid.net/

    OpenID allows you to use an existing account to sign into multiple websites, without needing to create new passwords

    You may choose to associate information with your OpenID that can be shared with the websites you visit, such as a name or email address

    With OpenID, your password is only given to your identity provider, and that provider then confirms your identity to the websites you visit. Other than your provider, no website ever sees your password

  • OpenID Authentication The end-user interacts with a relying party (such as website) that provides an option to specify an OpenID for purposes of authentication

    The relying party and the OpenID provider establish a shared secret, which the relying party then stores

    The relying party redirects the end-user's user-agent to the OpenID provider so the end-user can authenticate directly with the OpenID provider

    If the end-user accepts the OpenID provider's request to trust the relying party, then the user-agent is redirected back to the relying party

OpenID Authentication

  • OAuth and OpenID Connect OAuth is directly related to OpenID Connect (OIDC) since OIDC is an authentication layer built on top of OAuth 2.0. OAuth is also distinct from XACML, which is an authentication policy standard

    OAuth can be used in conjunction with XACML where OAuth is used for ownership consent and access delegation whereas XACML is used to define the authorization policies (e.g. managers can view documents in their region)

  • OpenID Connect https://developers.google.com/identity/protocols/oauth2/openid-connect

    OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol

    It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner

    OpenID Connect allows clients of all types, including Web-based, mobile and JavaScript clients, to request and receive information about authenicated sessions and end-users

    The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and session management, when it makes sense for them

    OpenID Connect

Risk Rating Methodologies

Risk Rating Introduction

https://owasp.org/www-community/OWASP_Risk_Rating_Methodology

  • When and Why do we risk rate

    • Risk Rating should be completed when there is a finding from a review of the application architecture/design from threat modeling, through a code review, or a penetration test
    • The goal of risk rating is to identity the risk to the system and business in order to put a plan in place to address the risk through prioritization

  • OWASP Risk Rating RISK = LIKELIHOOD * IMPACT

  • Risk Rating Method Risk Rating Method

    1. Identify a risk
    The first step is to identify a security risk that needs to be rated. The tester needs to gather information about the threat agent involved, the attack that will be used, the vulnerability involved, and the impact of a successful exploit on the business

    2. Estimating Likelihood
    Once the tester has identified a potential risk and wants to figure out how serious it is, the first step is to estimate the "likelihood". At the highest level, this is a rough measure of how likely this vulnerability is to be uncovered and exploited by an attacker

    Here you are using the Threat Agent Factors and Vulnerability Factors

    • Factors

      • Threat agent
        The goal here is to estimate the likelihood of a successful attack by this group of threat agents. Use the worst-case threat agent

        • Skill Level (How technically skilled is this group of threat agents?)
        • Motive (How motivated is this group of threat agents to find and exploit this vulnerability?)
        • Opportunity (What resources and opportunities are required for this group of threat agents to find and exploit this vulnerability?)
        • Size (How large is this group of threat agents?)

      • Vulnerability
        The goal here is to estimate the likelihood of the particular vulnerability involved being discovered and exploited. Assume the threat agent selected above.

        • Ease of Discovery (How easy is it for this group of threat agents to discover this vulnerability?)
        • Ease of Exploit (How easy is it for this group of threat agents to actually exploit this vulnerability?)
        • Awareness (How well known is this vulnerability to this group of threat agents?)
        • Intrusion Detection (How likely is an exploit to be detected?)

    3. Estimating Impact
    When considering the impact of a successful attack, it is important to realize that there are two kinds of impacts. The first is the "technical impact" on the application, the data it uses, and the functions it provides. The other is the "business impact" on the business and company operating the application

    • Factors

      • Technical Impact
        Technical impact can be broken down into factors aligned with the traditonal security areas of concern: confidentiality, integrity, availability and accountability. The goal is to estimate the magnitude of the impact on the system if the vulnerability were to be exploited

        • Loss of confidentiality (How much data could be disclosed and how sensitive is it?)
        • Loss of integrity (How much data could be corrupted and how damaged is it?)
        • Loss of availability (How much service could be lost and how vital is it?)
        • Loss of accountability (Are the threat agents' actions traceable to an individual?)

      • Business Impact
        Business impact stems from the technical impact but requires a deep understanding of what is important to the company running the application. In general, you should be aiming to support your risks with business impact, particularly if your audience is executive level. The business risk is what justifies investment in fixing security problems

        • Financial damage (How much financial damage will result from an exploit?)
        • Reputation damage (Would an exploit result in reputation damage that would harm the business?)
        • Non-compliance (How much exposure does non-compliance introduce?)
        • Privacy violation (How much personally identifiable information could be disclosed?)

    4. Determine the severity of the risk
    In this step the likelihood estimate and the impact estimate are put together to calculate an overall severity for this risk. This is done by figuring out whether the likelihood is low, medium or high and then do the same for impact

    • Informal
      In many environments, there is nothing wrong with reviewing the factors and simply capturing the answers. The tester should think through the factors and identify the key "driving" factors that are controlling the result
    • Repeatable
      If it is necessary to defend the ratings or make them repeatable, then it is necessary to go through a more formal process of rating the factors and calculating the result
    • Sample Determine severity of risk

    Determine severity of risk (2)

    5. Deciding what to fix
    After the risks to the application have been classified, there will be a prioritized list of what to fix. As a general rules, the most severe risks should be fixed first. It simply does not help the overall risk profile to fix less important risks, even if they are easy or cheap to fix

    Remember that not all risks are worth fixing, and some loss is not only expected, but justifiable based upon the cost of fixing the issue. For example, if it would cost $100,000 to implement controls to stem $2,000 fraud per year, it would take 50 years return on investment to stamp out the loss. But remember there may be reputation damage from the fraud that could cost the organisation much more

    • Handling risk

      • Accept
        Document the risk, acknowledge it and assign ownership
      • Avoid
        Place other controls that will reduce or eliminate the risk
      • Mitigate
        Fix the issue that exposes you to risk
      • Transfer
        If you are practically unable to deal with a risk, you may contractually obligate someone else to accept the risk

    • Threat Mitigation Examples Threat Mitigation Examples

    • Which one to use Which one to use

Threat Modeling

Threat Modeling is a structured approach to identify, quantify, and address the security threats and risks associated with an application
Threat modeling is an investigative technique for identifying application security risks/hazards that are technical (and even implementation specific)

  • Abuser

    • Abusers are those who would misuse intentionally or unintentionally an element of the system under consideration
    • Hactivist
    • Cyber Criminals
    • Advanced Persistent Threats

  • Asset

    • An Asset is anything we deem to have value

      • that which the system must protect from abusers

    • Money

    • Precious metals

    • House, car

    • Data (PHI, PII, PCI)

  • Threats

    • A threat is a means by which an abuser might compromise an asset that has potential for success
    • Threats can include everything from hackers and malware, from earthquakes to wars
    • Intention is not a factor when considering threats, thus the mechanical failure of a typical platter hard drive is a threat as is a coordinated attack by attacker

  • Hazard vs Threat

  • A hazard is a potential source of harm or danger

  • A harmless state with potential to change into a threat

  • A threat is a specific type of hazard involving an abuser potentially harming an asset

  • In a harmful state

  • Tree hazards include dead or dying trees, dead parts of live trees, or unstable live trees that are within striking distance of people or property (a target) Hazard trees have the potential to cause property damage, personal injury or fatality in the event of a failure

  • Risk
    Risk - The potential for loss, damage or destruction of an asset as a result of a threat exploiting a vulnerability
    Based on the previous example, mechanical failure of a hard drive is probably more likely than an attack by an attacker, but the overall impact might be significantly lower thus making it less risky

  • Identify, Quantify and Address Risks and Threats

    • Do not trust your gut feeling
      As humans we are naturally inclined to make immediate decisions based upon a feeling
      No Hollywood scenarios. Be realistic.

      • Which of these is a bigger risk?
        • Falls from stairs kill over 1,500 people per year
        • Bears kill, on average, 1 person per year
          Obviously the bear in this case provides a bit of sense of risk whereas the stairs maybe not but more people are killed per year by stairs than by bears. We walk up and down the stairs everyday and we do not see bears very frequently, maybe not even at all in our lifetime. However, stars are far more likely to kill you than a bear.

  • Scope Common phrases that distract (these should still be identified in the threat model):

    • "Well, the attacker would need to be on the internal network"
    • "That is only exploitable under this condition"
      If you have questions can't answer right now, do not get blocked. Concentrate on what you know. Document what you do not know to find out later
      Document any assumptions you make and follow up on them later

  • Assumptions

    1. You should not assume you have a secure environment (In most cases, you do not have control over it)
    2. You should not assume that compute, network, or storage resources are reliable (Can an application successfully survive loss of storage, network outages, etc, and stay healthy?)
    3. But when threat modeling we should not assume that your environment is correctly configured

  • Defense in Depth

    • The principle of defense-in-depth is that layered security mechanisms increase security of the system as a whole
    • In theory in defense-in-depth, you never make a tradeoff between performance and security but in reality you do, and in order to properly calculate those choices you need the full context of your stack

  • Benefits Threat Modeling Benefits

Types of Threat Models

  • Threat Model Manual vs Tools

    • Manual
      • More favorable in terms of quality and custom-ability
      • Just need a whiteboard, group of experts on the product and security
      • However, not scalable
    • Using a tool
      • More scalable
      • Not always consensus on the tool
        • Some may use Wiki, PPT, Visio, architecture tool, or a TM tool
      • Can lead to a "check the box mentality"

  • Threat Model Types

    • Octave: Operational Critical Threat Asset and Vulnerable Evaluation

      • Focuses on non-technical risk that result from breached data assets
      • Assets are identified and classified. This helps define the scope
      • Drawback is that as systems grow, re-doing the id and classification can be difficult

    • PASTA: Process for Attack Simulation and Threat Analysis (Business Impact)

      • Takes an attacker view and then develops a threat management, enumeration, and scoring process. This can then be elevated to key decision makers to determine what risk to tackle opposed to developing requirements at the SDLC level

    • STRIDE (Technical Impact)

      • Used in MS-TM and MS SDL (Security Development Lifecycle) and one that is generally easy to follow if doing a manual threat model
      • Builds a DFD used to identify system entities, events, and boundaries and applies a general set of known threats using the mnemoic

  • Spoofing

    • Definition
      One person or program successfully masquerades as another by falsifying data, thereby gaining an illegitimate advantage

    • Example
      Threat action aimed to illegally access and use another user's credentials, such as username and password

    • Security Control
      Authentication

  • Tampering

    • Definition
      Intentional modification of products in a way that would make them harmful to the consumer

    • Example
      Threat action aimed to maliciously change/modify persistent data, such as persistent data in a database, and the alteration of data in transit between two computers over an open network, such as the Internet

    • Security Control
      Integrity using hashing algorithms, checksum

  • Repudiation

    • Definition
      State of affairs where the author of a statement will not be able to successfully challenge the authorship of the statement or validity of an associated contract

    • Example
      Threat action aimed to perform illegal operations in a system that lacks the ability to trace the prohibited operations

    • Security Control
      Non-Repudiation using encryption, digital signatures, and notarization

  • Information Disclosure

    • Definition
      The interntional or unintentional release of secure or private/confidential information to an untrusted environment

    • Example
      Threat action to read a file that one was not granted access to, or to read data in transit

    • Security Control
      Confidentiality through encryption

  • Denial of Service

    • Definition
      Is a cyber-attack where the perpetrator seeks to make a machine or network resource unavailable to its intended users by temporarily or indefinitely disrupting services of a host

    • Example
      Threat aimed to deny access to valid users, such as by making a web server temporarily unavailable or unusable

    • Security Control
      Availability

  • Elevation of Privileges

    • Definition
      Is the act of exploiting a bug, design flaw or configuration oversight in an operating system or software applciation to gain elevated access to resources that are normally protected from an application or user

    • Example
      Threat aimed to gain privileged access to resources for gaining unauthorized access to information or to compromise a system

    • Security Control
      Authorization

Maual Threat Modeling

  • Best done in groups Including:

    • Implementation expert (an architect)
    • Solution designer
    • Implementation team
    • Should include a security SME
    • Group should be a manageable size (6-8 people)

  • Audience

    • Your team
      The treat model becomes a reference for understanding the security of your solution, and therefore is like system level tech design

    • Other teams
      Other teams may rely on your components to understand their own security. Threat models should reference related threat models

    • Pen testers
      This is a map to potentially hacking the application

    • Clients
      Your clients may ask to see if you are considering security. You would most likely hand over a high level and not a raw threat modal

    • Threat Modeling mindset

      • What are you building?
        What is the scope, What do you own
      • What can go wrong? Realistic
      • What should you do about those things that can go wrong?
        Mitigations, Counter Measures
      • Did you do a decent job of analysis?
        Retrosepective, Did you capture all the points

  • Threat Models are never complete
    This is a living artifact expected to change and grow over time. A complex system is never truly complete

  • Sample Board Threat Model Sample Board

  • Example Retail Store User Stories
    Retail Store User Stories
    Retail Store Architecture
    Retail Store Architecture
    Components of the System
    Components of the System
    Who, Why, What, How, Impact/Counter
    Who, Why, WHat, How, Impact/Counter
    Create the Board Create the Board

Threat Modeling with Microsoft Threat Modeling Tool

1. Creating the Model

  • System Model

  • Find Threats

  • Address Threats

  • Validate Model


    Using Microsoft Threat Model, the architecture is drawn out.
    The diagram should be as in depth as possible, but should be not so much that it is distracting.
    The scope of the diagram should be identified.

  • Things to consider

    • Scope
    • System components (e.g. databases, mail servers, etc)
    • Backups, monitoring, logging, etc.
    • Actors/Abusers
    • Process and data flows (e.g. cookies, tokens, etc)

  • A note about Scoping
    This is a combination of a workflow diagram and an architecture diagram.
    The purpose of scoping small is to concentrate on a small part of the system so you can get to the end of the threat modeling process.
    Boil down a workflow to something as small as you can.
    For a reasonably complex system, you would otherwise never reach the end.

2. Create a diagram

  • The diagram must help you understand and discuss system security considerations

  • The diagram should contain the items determined in Step 1. It is okay if you missed things you can always go back and break things down further or remove items as you gain a better view of the system

  • The diagram should show components, data stores, data flows and trust boundaries
    Diagram Essentials

  • Do not create an eye-chart

  • Sample
    Simple Web Application

    • Accounts (UIDs on unix saystems, or SIDS on Windows) Network interfaces
    • Different physical computers
    • Virtual machines
    • Organizational boundaries
    • Almost anywhere you can argue for different privileges

3. Identify and Analyze threats

  • What can go wrong
    Now that you have a diagram, you can really start looking for what can go wrong with its security.
    Classifying threats using STRIDE:
    • Spoofing
    • Tampering
    • Repudiation
    • Information Disclosure
    • Denial of Service
    • Elevation of Privilege
  • Getting Started
    • If you are not sure where to start, start with the external entities or events which drive activity
    • Wherever you choose to begin, you want to aspire to some level of organisation
    • You could also go in "STRIDE order" through the diagram
    • Without some organisation, it is hard to tell when you are done, but be careful not to add so much structure that you stifle creativity

Example Microsoft Threat Modeling Tool

Encryption and Hashing

Encryption

  • Encryption Types

    • Symmetric Encryption

      • Allows for encryption and decryption
      • Same key is used to encrypt and decrypt data
      • Example: Use this for storing sensitive data in a database
        Symmetric Encryption

      • AES
        AES has been adopted by the U.S. government and is now used worldwide. It supersedes the Data Encryption Standard (DES),[9] which was published in 1977

      • Blowfish
        Blowfish provides a good encryption rate in software and no effective cryptanalysis of it has been found to date

      • 3DES
        A symmetric-key block cipher, which applies the DES cipher algorithm three times to each data block


      Older, less security algorithms: DES, RC4

    • Asymmetric Encryption

      • Allows for encryption and decryption, as well as repudiation
      • One key is used to encrypt and another key is used to decrypt data
      • Example: Verify that a message came from an individual using their private key
      • Keys are generated together
      • Public keys are freely distributed
      • Private keys are kept secret and never handed out
      • Private key is used for Encryption/Decryption and Signing
        Asymmetric Encryption

  • RSA

    • RSA (Rivest-Shamir-Adleman) is the most widely used asymmetric. Used for encryption and digital signatures
    • In RSA cryptography, both the public and the private keys can encrypt a message; the opposite key from the one used to encrypt a message is used to decrypt it
    • It provides a method of assuring the confidentiality, integrity, authenticity and non-reputability of electronic communications and data storage

  • Symmetric vs Asymmetric Symmetric vs Asymmetric

Encryption Use Cases

  • 1. Use Case 1: HTTPS - Encryption
    HTTPS Encryption
    Most websites today are using HTTPS. This is basically a way to encrypt the connection between your browser and the server. For instance, maybe you are going to Amazon/Facebook/Google, your browser will be able to encrypt that traffic that is going to the server.
    So one of the primary components of this HTTPS is certificates. Certificates are a way for a third party to vouch for the owner of a private key. And basically that means that a server with private and public key pairs, with asymmetric encryption, a server will get a private and public keeper and they will go out to a third party (entrust data card) The server or the owner of the server will go out to a third party and get a certificate. The certificate is signed. Therefore, it vouches for the servers ownership of that private key (that certificate is then used to pass out publicly - public key [the other half of that asymmetric key])
    The certificate is then used by browser. When it goes to Amazon/Facebook/Google, the browser will have the entrust data card certificate in its rolodex of certificates, and therefore, it knows that it will trust the server owns the private key.
    Public key: embedded within certificate
    Private key: stay private on the server
    Asymmetric encryption allows the client/browser to encrypt any of the traffic going to the server and server is the only one that can decrypt it because it is the only one that has the private key.

  • 2. Use Case 2: Digital Signatures
    Signing Encryption

      1. You have a document - Medical Record
      1. You hash that document to fixed size gibberish
      1. The gibberish is the fingerprint of the document
      1. Use your private key you sign the fingerprint
      1. This produces the digital signature of the document
      1. Append this signature to the document

    You are going to hash the document so it is going to be gibberish (not the same document - fingerprint/checksum/fixed size of gibberish) You use your private key to sign that output from the hash. This produces a digital signature of the document. So because you used your private key to sign, you are the only one that has ownership of that privacy and therefore you are the only own that could have signed that document.
    To create the digital signature, you penned this to the document and this provides digital signature to that document. So if you want to verify that document first, you would take the public key and decrypt it to get the hash (only private key could have encrypted it) And if those two hashes match, that means that the document has not been modified (provides you both integrity and repudiation)

  • 3. Use Case 3: Signing with Security
    Signing with Security
    Alice is the one that created the document which is going to send it over to Bob.

      1. Alice has a document
      1. Alice is going to hash the document and create fingerprint
      1. With her private key, she is going to sign that fingerprint and create a digital signature (provides authentication)
      1. She takes a symmetric key and encrypt the document
      1. She is going to take Bob's public key to encrypt that symmetric key (provides security)
      1. She then send both the encrypted document and symmetric key over to Bob
      1. Bob is able to take his private key and decrypt that symmetric key
      1. Once he has that symmetric key decrypted, he can then decrypt the encrypted document
      1. With Alice's public key, Bob is able to verify by decrypting that digital signature
      1. He hashes that decrypted document with a symmetric key and if two of those matched, then he knows that the document has not been tampered with (provides integrity) And if Alice wants to get verification, she will ask Bob to sign what he hash with his private key and send back over to Alice. Alice uses Bob's public key to decrypt that digital signature and gets the fingerprint of the document that Bob actually hashed. And if that matches to her original, then we know that there is verification that Bob received it

  • Key Management

    • The algorithms that encrypt the data are all the same (what makes it secure is the keys)
    • As organisations use more encryption, they also end up with more keys, and more varieties of keys
    • In some companies, you might have millions of keys. And every day, you generate mroe keys and they have to be managed and controlled. If the bad guy gets access to the keys, he gets access to the data. And if the keys get lost, you cannot access the data
    • Other factors that contributed to the pain were fragmented and isolated systems, lack of skilled staff and inadequate management tools

Hashing

  • Hash
    Hash

    • One-way. Not possible to reverse
    • Collision Resistant (given an input and its hash, it should be hard to find a different input with the same hash)

  • Uses for Hashing

    • Digital Signatures
    • Passwords
    • Blockchains
    • Identifying whether a file has been modified

  • Salt
    Salt

    • Random data of fixed length
    • Concatenated to input before hashing
    • Unique for each input
    • Used to make hashes unique and protect against brute force style attacks

  • Hash Functions

    • MD5
      Producing a 128-bit hash, MD5 is a widely used, however not very secure hashing algorithm. It can still be used as a checksum to verify data integrity, but only against unintentional corruption
    • SHA-1
      Produces a 160-bit hash value. Since 2005, SHA-1 has been considered insecure against robust attacks. Since then, it has been deemed as insecure as MD5
    • SHA-2
      SHA-2 includes significant changes from its predecessor. The SHA-2 family consists of six hash functions with digests (hash values) that are 224, 256, 384 or 512 bits
    • SHA-3
      The latest iteration of the SHA family with a varied outputs of 224, 256, 384 or 512 bits

  • Hash Attacks

    • A Hash Collision Attack is an attempt to find two input strings of a hash function that produce the same hash result. Because hash functions have infinite input length and a predefined output length, there is inevitably going to be the possibility of two different inputs that produce the same output hash
      • Birthday attacks
        This applies to finding collisions in hashing algorithms because its much harder to find something that collides with a given hash than it is to find any two inputs that hash to the same value
        Example: A classroom of 30 students and a teacher. The teacher wishes to find pairs of students that have the same birthday
        • The teacher asks for everyone's birthday to find such pairs
        • For example, if the teacher fixes a particular date say October 10, then the probability that at least one student is born on that day is about 7.9%
        • However, the proability that at least one student has the same birthday as any other student is around 70%
          Birthday Attack
      • Brute Force
        In cryptography, a brute-force attack consists of an attacker trying many passwords to passphrases with the hope of eventually guessing correctly
      • Dictionary
        A technique for defeating a cipher or authentication mechanism by trying to determine its decryption key or passphrase by trying hundreds or sometimes millions of likely possibilities (words in a dictionary)
      • Rainbow table
        A rainbow table is a precomputed table for reversing cryptographic hash functions, usually for cracking password hashes

Public Key Infrastructure (PKI)

  • Digital Certificate

    • Identity and proof of key ownership
    • It is digital representation of an Identity, and it allows one to confirm with who you are transferring data to/from
    • A certificate binds an entity's unique distinguished name (DN) and other additional attributes that identifies an entity with a public key associated with its corresponding private key

    In cryptography, a certificate authority or certification authority (CA) is an entity that issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate.
    ![Digital Certificate](image/README/Digitial%20Certificate.png) - Certificate Authorities are the foundation of PKI - Offloads the trust to a third party - Relying parties can rely on signatures or assertions that correspond to the certificate being presented

  • Public Key Infrastructure (PKI)

    • A highly protected ecosystem that allows for businesses to issue trusted Digital Certificates
    • There is a chain of trust in the issuing and root CA's and many cases the root certificate is "offline" only used when cutting a certificate for an issuing CA. This protects the root. PKI

  • Certificate Signing Request (CSR) CSR CSR (2) CSR (3)

Password Management

  • Password Handling - Best Practices
    https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/

    • Align password length, complexity and rotation policies with National Institute of Standards and Technology (NIST) 800-63b's guidelines in section 5.1.1
    • Implement multi-factor authentication to prevent credential stuffing, brute force and stolen credential reuse
    • Limit failed login attempts
    • Used advanced authentication methods (biometrics, PKI, passwordless tech)
    • Always transmit over secure, encrypted channels. Store securely using hashing
    • Make sure passwords are never logged in log files
    • Do not utilize default passwords when deploying (especially for admin/privilege accounts)
    • Check passwords against the top 10k weak passwords: https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/10-million-password-list-top-100000.txt

  • Password Storage - Best Practices
    https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

    • Never store passwords in plain text, only one-way hashes
    • Use a cryptographically strong hash algorithm
      • Argon2id, scrypt, bcrypt or PBKDF2 depending on requirements
    • Use sufficient "salt" during hashing and do not reuse "salt" values
    • Physically segregate stored hashes from the rest of application data

  • Entropy

  • Password Entropy

    • Password entropy is based on the character set used (which is expansible by using lowercase, uppercase, numbers as well as symbols) as well as password length
    • Password entropy predicts how difficult a given password would be to crack through guessing, brute force cracking, dictionary attacks or other common methods
    • Note: Encryption creates randomness which cannot be compressed as well. For maximum efficiency you should compress before encrypting

Frameworks and Process

Health Insurance Portability and Accountability Act (HIPAA)

  • Data Classification

    • Restricted (Highly sensitive information)
    • Confidential (Sensitive information)
    • Internal (Non-sensitive information that is not released to the public)
    • Public (Information has been approved for public access)

  • Types of Data Types of Data

  • Overview of HIPAA

    • Signed in 1996, HIPAA (Health Insurance Portability and Accountability Act) aimed to:
      • Modernize the flow of healthcare information
      • Provide protection of PII (Personally Identifiable Information)
      • Address limitations on healthcare insurance coverage

  • HIPAA Titles

    • Title I - Health Care Access, Portability and Renewability
    • Title II - Preventing Healthcare Fraud and Abuse; Administrative Simplification; Medical Liability Reform
      Title II
    • Title III - Tax-related health provisions governing medicial savings accounts
    • Title IV - Application and enforcement of group health insurance requirements
    • Title V - Revenue offset governing tax deductions for employers

  • What is PHI PHI

  • Privacy in HIPAA

    • With respect to health information, privacy is defined as the right of an individual to keep his/her individual health information from being disclosed. This is typically achieved through policy and procedure
      • Privacy encompasses controlling who is authorized to access patient information; and under what conditions patient information may be accessed, used and/or disclosed to a third party

    HIPAA Violation Penalties

  • The Health Information Technology for Economic and Clinical Health Act (HITECH Act) HITECH

    • Built on HIPAA and ensured entities were complying with HIPAA Rules and that notifications were sent to affected individuals when health information was compromised
    • Tougher penalties for HIPAA compliance failures were introduced to incentivize entities to comply with the HIPAA Privacy and Security Rules
    • Transitioning to electronic records was expensive. The Act introduced incentives to encourage hospitals and other healthcare providers to make the change
    • Increase HER adoption from 3.2% in 2008 to 14.2% in 2015
    • By 2017, 86% of office-based physicians had adopted an EHR and 96% of non-federal acute care hospitals has implemented certified health IT
    • The Act did not make compliance with HIPAA mandatory as that was already a requirement, but it did make sure that entities found not to be in compliance could be issued with a substantial fine

  • HITECH and HIPAA

    • HIPAA and HITECH were brough together in 2013 through the HIPAA Omnibus Final Rule
    • The HITECH Act called for mandatory penalties for HIPAA-covered entities and business associates in cases where there were willful neglect of HIPAA Rules
    • With such high potential fines (up to $1.5 million), HIPAA compliance could no longer be considered "optional". The penalties could be higher than the cost of complying with HIPAA
    • The HITECH Act brought the new HIPAA Breach Notification Rule required entities to issue notifications to affected individuals within sixty days of the discovery of a breach of unsecured protected health information
    • Both Acts address the security of electronic Protected Health Information (ePHI) However, prior to HITECH, patients were unable to find out who their ePHI had been disclosed to (both authorized and unauthorized where known) In 2011, a HITECH-required Rule allows patients to request access reports

Payment Card Industry Data Security Standard (PCI DSS)

  • PCI PCI

    • Qualified Security Accessor (QSA)
      A Qualified Security Assessor is a certificate that has been provided by the PCI Security Standards Council. This certified person can audit merchants for Payment Card Industry Data Security Standard (PCI DSS) compliance

    • Report on Compliance (ROC)
      A Report on Compliance is a form that has to be filled by all level 1 merchants undergoing a PCI DSS (Payment Card Industry Data Security Standard) audit. The ROC form is used to verify that the merchant being audited is compliant with the PCI DSS standard

    • Self-Assessment Questionnaire (SAQ)
      The Self-Assessment Questionnaire is a set of Questionnaires documents that merchants are required to complete each and every year and submit to their transaction Bank


    Validation of compliance is performed annually, either by an external Qualified Security Assessor (QSA) or by a firm specific Internal Security Assessor that creates a Report on Compliance (ROC) for organizations handling large volumes of transactions, or by Self-Assessment Questionnaire (SAQ) for companies handling smaller volumes
    Compliance with PCI DSS is not required by federal law in United States. However, the laws of some U.S. states either refer to PCI DSS directly, or make equivalent provisions
    The PCI Data Security Standard specifies twelve requirements for compliance, organised into six logically related groups called "control objectives"
    ![PCI DSS](image/README/PCI%20DSS.PNG)

DEVOPS and CICD

  • CICD

    • Continuous Integration (CI)
      • Automation that delivers software more frequently to an environment
      • Continuous Integration is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early

      ![CI](image/README/CI.PNG)
      ![CI (2)](image/README/CI%20(2).PNG)
    • Continuous Delivery/Deployment (CD)
      • Continuous Deployment
        The ability to get changes of all types into production, or into the hands of users, safely and quickly in a sustainable way
      • Continuous Delivery
        The ability for a team to perform all integration tasks and make a production ready package ready and available

      The difference between continuous deployment and continuous delivery is that in continuous delivery, the package is not pushed to a production environment without manual intervention
      ![CD](image/README/CD.PNG)

  • DEVOPS DEVOPS
    DEVOPS (2)

DEVSECOPS

  • How do we inject security
    How do we inject security
    Devsecops

  • DEVOPS vs DEVSECOPS Tools
    Devops vs Devsecops
    Unit Test -> Integration Test -> System Test -> Manual Validation -> Deployment
    Devops vs Devsecops(2)

  • Bottom Line

    • Test early, Test often
    • Use the scanning tools available and scan smaller scopes
    • DAST, RASP, IAST, WAF work better in a DEVOPS environment than SAST
    • Constant feedback loop of communication
    • Monitoring for vulnerabilities in the environment
    • Monitoring external sources for vulnerabilities in 3rd parties

Abuse/Misuse cases

  • Use Case

    • In software and systems engineering, a use case is a list of actions or event steps typically defining the interactions between an actor and a system to achieve a goal
    • The actor can be a human or other external system

  • Abuse/Misuse case

    • A misuse case highlights something that should not happen (e.g. Negative Scenario) and the threats hence identified, help in defining new requirements, which are expressed as new Use Cases

    • An abuse case is a type of complete interaction between a system and one or more actors, where the results of the interaction are harmful to the system, one of the actors, or one of the stakeholders in the system

    • Sample
      Abuse or Misuse

Security Scanning and Testing

Static Application Security Testing (SAST)

  • Security Analysis

    • General Guidance
      • Most enterprises use many (even all) of the techniques outlined here
      • Not each solution is a silver bullet
      • Many solutions are platform or language dependent
        • This means that if you are using multiple platform or languages you will need more than one tool (very few enterprises are monolithic)
      • Results are different in each solution and there are many false positives
      • You may be mandated by your environment to run tools
        • Government, financial, healthcare, etc.
      • Every vendor will tell you their solution fits your needs
        • They tell you your problem, then sell you their solution

      False positive - A finding in a tool or through some other technique that turns out to not be a viable finding
      Example: Tools that claim there is a password in clear text when it simply found the word "password" in the code

      False negative - A vulnerability that is able to get past a scanning tool or other technique that is looking for vulnerabilities
      Example: A SQL injection vulnerability that is not identified by a scanning tool

  • Static Analysis

    • How static Analysis works

      • Static Code Analysis commonly refers to the running of Static Code Analysis tools that attempt to highlight possible vulnerabilities within "static" (non-running) source code by using techniques such as Taint Analysis and Data Flow Analaysis
      • Most static analysis tools are used as an aid for an analyst to help zero in on security relevant portions of code so they can find flaws more efficiently, rather than a tool that simply finds flaws automatically

    • Taint and Lexical Analysis

      • Taint Analysis attempts to identify variables that have been "tainted" with user controllable input and traces them to possible vulnerable functions also known as a "sink". If the tainted variable gets passed to a sink without first being sanitized it is flagged as a vulnerability
      • Lexical Analysis converts source code syntax into "tokens" of information in an attempt to abstract the source code and make it easier to manipulate

    ![SAST](image/README/SAST.PNG)

  • Strengths

    • Helps in identifying the flaws in code
    • The testing is conducted by trained software developers with good knowledge of coding
    • It is fast and easy way to find and fix the errors
    • With automated tools, it becomes quite fast to scan and review the software
    • The use of Automated tools provides mitigation recommendations
    • With static testing it is possible to find errors at an early stage of development life cycle, thus, in turn reduces the cost of fixing

  • Weakness

    • Demand great amount of time when done manually
    • Automated tools works with few programming languages
    • Automated tools may provide false positives and false negatives
    • Automated tools only scan the code
    • Automated tools cannot pinpoint weak points that may create trouble in run-time

  • Static Analysis Tools Static Analysis Tools

Dynamic Application Security Testing (DAST)

  • Dynamic Application Security Testing (DAST)

    • DAST is a black-box security testing methodology in which an application is tested from the outside in by examining an application in its running state and trying to attack it just like an attacker would
      • DAST scanners are for the most part, technology independent. This is because DAST scanners interact with an application from the outside-in and rely on HTTP as a common language across a myriad of programming languages, off-the-shelf and even custom-built frameworks

  • Strengths

    • Not as technology dependent
    • Can be run in production
    • Not as many false positives
    • Can test software that you do not own
    • Can be used to enhance penetration testing

  • Weakness

    • Cannot locate the line of code
    • Findings are later in the SDLC - Although you can do dynamic scanning earlier
    • Does not locate code specific security issues (e.g. hard coded passwords)
    • Findings still need to be verified by a subject matter expert

  • DAST Tools DAST Tools

Interactive Application Security Testing (IAST)

  • Interactive Application Security Testing (IAST)

    • Assesses applications from within using software instrumentation
    • This technique allows IAST to combine the strengths of both SAST and DAST methods as well as providing access to code, HTTP traffic, library information, backend connections and configuration information
    • Some IAST products require the application to be attacked, while others can be used during normal quality assurance testing

  • Strengths

    • Agents - installing agents mean that there is continuous monitoring that is always active
    • Works well in the DevOps (or DevSecOps) model
    • Lower cases of false positives since it can "see" active attacks and not potential ones
    • Can have a targeted approach to defining the security scope

  • Weakness

    • Agents - In the real world, agents are resisted because the owners of systems are not always sure of what the agent is doing
    • Instrumentation means possibly development and deployment work in order to take advantage of the benefits
    • Many of them only work wehen they "see" something. In other words, you need to exercise a workflow in order for it to be picked up
    • Steep learning curve for deployment and reviewing the results since it does not point to the line of code (see dynamic analysis)

  • IAST Tools
    IAST Tools

Run-Time Application Security Protection (RASP)

  • Run-Time Application Security Protection (RASP)

    • Is a security technology that uses runtime instrumentation to detect and block computer attacks by taking advantage of information from inside the running software
    • RASP technology can improve the security of software by monitoring its inputs, and blocking those that could allow attacks, while protecting the runtime environment from unwanted changes and tampering
    • RASP can prevent, exploitation and possibly take other actions, including terminating a user's session, shutting the application down, alerting security personnel and sending a warning to the user

  • Strengths

    • Can be configured to block or monitor
    • Can block attacks as they happen
    • Since this is similar to DAST and IAST (in fact this commonly referred to as a combination of both) see the strengths listed in those tools

  • Weakness

    • Needs to see an attack as it happens (see IAST)
    • Potential to block legitimate traffic
    • Someone (or some group) needs to own the rules that define what is blocked
    • Since this is similar to DAST and IAST (in fact this is commonly referred to as a combination of both) see weaknesses listed in those tools

  • RASP Tools
    RASP Tools

Web Application FireWall (WAF)

  • Web Application FireWall (WAF)

    • Is an application firewall for HTTP applications. It applies a set of rules to an HTTP conversation. Generally these rules cover common attacks such as cross-site scripting (XSS) and SQL injection
    • It is deployed in front of web applications and analyzes bi-directional web-based (HTTP) traffic - detecting and blocking anything malicious
    • This functionality can be implemented in software or hardware, running in an appliance device, or in a typical server running a common operating system
    • WAFs may come in the form of an appliance, server plugin, or filter, and may be customized to an application
    • Note: WAF's can sometimes be considered an ASM (Application Security Manager)

  • WAF Deployment

    • Although the names for operating mode may differ, WAFs are basically deployed inline as:

      • Transparent bridge
        It inspects only the traffic that is configured for inspection while bridging all other traffic. Bridge mode deployment can be achieved with no changes to the network configuration of the upstream devices or web servers

      • Reverse proxy
        Reverse proxy deployments accept traffic on the virtual IP address and proxy the traffic to the back-end server network behind the Web Application Firewall


    WAF

  • Strengths

    • Can be in blocking or reporting mode
    • Can be independent of the application
    • Can block the following:
      • Cross-site Scripting (XSS)
      • SQL injection
      • Cookie poisoning
      • Unvalidated input
      • DoS
      • Web Scripting

  • Weakness

    • Potential performance issues
    • Not actually solving the problems
    • Cannot protect against every security issue

  • Types of WAF's

    • Network Based
      • Pro: Low network latency since they are connected directly to the web servers
      • Con: Higher Cost and Tougher Management across large DCs
    • Host Based
      • Pro: Affordable. No network latency
      • Con: Agents. Engineering costs/time. Can create complexity with application
    • Cloud Based
      • Pro: Cheapest. Auto update/maintained. Quick to deploy
      • Con: High network latency. No ownership

Penetration Testing

  • Types

    • White Box
      Provides information about the system to the tester. This can include code, credentials, network maps and other system information

    • Black Box
      Provides little to no system information. This resembles a typical attack where the information that can be gathered is generally only public information

    • Grey Box
      The in-between state. Some information but possibly limited to just essential information

    • Internal
      A team that is employed at the target company. This is a team/group that has other duties at the company, but is engaged for a period of time to target a specific system/application

    • External
      An external party that is engaged to test the system/application. Scope is defined and the party is given a timeframe for completion

  • Strengths

    • Findings are typically true findings that are actionable
    • Can be scoped to specific areas and time
    • Can be used in combination with other security methods
      • Findings in threat model of scan tools can be verified

  • Weakness

    • Not usually a full system test, typically very targeted
    • Can be expensive and time consuming
    • Findings need to be secured, especially when a 3rd party is involved in the testing

Software Composition Analysis (SCA)

  • Software Composition Analysis (SCA)

    • SCA is the process of validating that the components, libraries, and opensource software that is used in an application is free from known vulnerabilities and license compliance

    • These external software components can come from several places:

      • Downloads
      • Commerical applications
      • Third party libraries and software
      • From outsourced development by consulting

    • SCA can provide:

      • Component tracking and inventory
      • Vulnerability identification and remediation recommendation
      • License management

    ![SCA](image/README/SCA.PNG)

  • Dependency Check

    • .NET and Java compatible, Dependency Check is used to scan libraries used as build dependencies during the build process
    • Dependencies are matched against the NVD (National Vulnerability Database) to determine whether the dependency being used is vulnerable
    • A report is generated and can be used to identify the dependencies as well as understand the mitigation (In mos t cases, the mitigation is to use the most up to date level of software)

  • National Vulnerability Database
    https://nvd.nist.gov/

    • The NVD is the U.S government repository of standards based vulnerability mmanagement data represented using Security Content Automation Protocol (SCAP) This data enables automation of vulnerability management, security measurement, and compliance
    • The NVD includes databases of security checklist references, security related software flaws, misconfigurations, product names and impact metrics

    NVD

    • Sample Dependency Check
    • JFrog Xray JFrog JFrog Xray

Conclusion

Secure Design and Coding

Secure Design and Coding

Secure Testing

Secure Testing

Remember the Basics

Remember the Basics

About

Developing security in the Software Development Life Cycle (SDLC)

Resources

Readme
Activity
Custom properties

Stars

0 stars

Watchers

1 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

No packages published